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Abstract 
The custom modifications of the Tucson Anateur Packet 


Radio TNC 2 software for the Shuttle Amateur Radio Experiment 


2 (SAREXz), and the associated operating nedes (robot, meta 
beacon, logging functions) are discussed. 


Background 


When Tom Clark W3IWI, president of the Amateur Satellite 
Corporation, told ne of the possiblity of a "Ham in Space" 
experiment involving packet radio and then held oqut the 
opportunity to nake use of the TNC2,1 jumped at the 
opportunity to get involved. We spoke an the phone a few 
times and arrived at some basic specifications for minimal 
functionality. Towards theendof the next month (Novenber 
1985) | finally had a version suitable for release and 
simultaneously placed it on the air in Florida and forwarded 
& Copy to the president af the Tucson Anateur Packet Radio 


Corporation {TAPR) Lyle Johnson WA7GXD, the man responsible 


fur getting flight-ready hardware together, 


Special Operating Modes. 
ROBOTMode 


Since it was most unlikely that the astronaut ham 
would be able to devote his or her entire time ta worki ng 
anateurs, one specification called for an unattended @QSO 
machine, comparable perhaps with the ROBOT nede that was M 
sone of the Soviet RS satellites. Such a feature vould 
maximize the potential nunber of amateurs who could make a 
confirmable, two way contacts with the vehicle, 


The package permits up to nine automated contacts to 
take place simultaneously using AX.25 link layer (version 2.0 
or earlier versions). Upon hearinga request to connect from 
aground station, the ROBOT assigns a QSO nunber, and builds 
a packet which contains the hexadecimal serial number 
concatenated with a brief, astronaut-settable nessage. The 
ROBOT acknowledges the connect request and proceeds to send 
this packet ten times, or until it correctly receives an 
acknowledgment frane fromthe station connecting. 


The pint at which the acknowledgement for the seal 
nunber and nessage are received is the point at which the 
contact is considered a valid two way and I ogged 
appropriately. Then the ROBOT will enter the 
di sconnect- attenpt state with the calling station, but 
success or failure on getting the disconnect acknowledgement 
is not significant to the two way legging function, 


Logging 


Part of the Specification also made it clear that 
the local terninal (.e. theone on the shuttle) would not 
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be available for logging the contacts and "heard" data, In 
this case how on earth (pun intended) can the ground crew 
ever reconcile claimed contacts wth what really happened? 
How could the lagging data be recovered? At this point it 
was decided to have the TNC transmit two special kind5 of 
franes every three minuted that the ground stations could 
collect and forward to a central paint for the 
reconciliation. 


One kind of lugging frame is of the format 
"WA4SIRSWORKED". The information field of this frane 
contains the last seventeen unique callsigns worked and their 
associated serial numbers, 


The other logging frane, “WA4SIR>HEARD" is similar to 
the *+WORKED" frame except there is a serial number 
associated with each distinct transmission of the "HEARD" 
frane, and of course there are no contact serial number5 
appended to callsigns since only the fact that the station 
was heard from orbit is significant. 


The log types are similar in the respect that a callsign 
worked or heard that is already logged will not cause a 
re-ordering of log, This "no update unless needed” 
philosophy should ease the data reduction chores of those who 
will be processing the hundreds or thousands of log franes 
the flight TNC will generate. 


Meta Beacons 


As the name implies, "Meta" beacon mode provided a 
way for the astronaut to downlink rdativedy large amounts - 
4,792 characters = of information at regular intervals f or 
the packet community at large Once set up "Meta” beacon 
node will continue to retransmit the data indefinitely. 


This customization was the simplest, requiring only that 
a dunny link with the callsign WORLD be recognized internally 
as onethat will always transmit packetized data yet ignore 
any retry counters {or recaved frames from WURLD for that 
natter), Meeting specifications should always be this easy! 


Conclusion 


Despite popular belief, it |S possible to balance the 
interests of the progranmer (who wants to minimize 
complexity) with the interest5 of the user di.e. maximize 
perfornance). A thorough specification of objectives goes a 
long way towards insuring the software ddivered does what it 
was assuned it would be capable of, And a specification 
developed jointly between programmer and requestor is one 
usually capable of being net by the desired delivery date, 


